Fixed and mobile communication terminals have so far been used mainly for making voice calls. The service of communicating limited text messages, such as SMS (Short Message Service) messages, is also used extensively by mobile terminals. These are fairly straightforward telecommunication services which use well-established technologies for chiefly circuit-switched single connections. In the standardized communication protocols used for calls between fixed and/or mobile terminals, predefined sets of communication rules and parameters are typically used.
A multitude of new telephony services are now rapidly being developed, which can be employed in particular by the introduction of new communication technologies which provide greater network capacity and higher transmission rates. For example, GPRS (General Packet Radio Service) and CDMA (Wideband Code Division Multiple Access) technologies are currently emerging for enabling wireless telephony services requiring a wide range of data rates and different protocols. The trend today is a move towards packet-switched networks and technologies providing more capacity and flexibility. Further, new sophisticated terminals for communication are also emerging on the market, adapted to handle the new services.
Many of the new services involve real-time transmission of video information as well as audio information, and may further include the transmission of added data representing text, documents, images, audio files and video files in a multitude of different formats and combinations. Such services are generally referred to as “multimedia” services, which term will be used in this description to represent any telephony services that involve the transfer of information in addition to ordinary voice. Another trend is to converge all services on to a single transport mechanism—the Internet Protocol (IP), regardless of the type of access networks and technologies.
Recently, a network architecture called “IP Multimedia Subsystem” (IMS) has been developed by the 3rd Generation Partnership Project (3GPP) as an open standard, to give operators of access networks the ability to offer multimedia services in the packet domain. An IMS network, comprising various different network elements to handle the services, can be built above any type of access network and is independent of the access technology used, provided that the access network is able to support the service requirements in terms of bandwidth, QoS (Quality of Service), etc. Hence, IMS is a platform for enabling services based on IP transport, not restricted to any limited specific set of services.
Two important examples of services that can be employed by means of the IMS solution are Instant Messaging (IM) and Presence services. In the IMS solution, presence services are supported by the “Session Initiation Protocol” (SIP) which has been defined by IETF as a generic session management protocol to support a wide range of IP-based services. SIP is purely a signalling protocol for creating, modifying and terminating communication sessions with one or more participants.
Instant Messaging involves the transmission of relatively short messages, e.g. including text, pictures, logos audio/video clips, etc., in “near real-time” between terminals, i.e. with small delays. In this context, “presence” is basically a dynamic and variable state profile of a user, and the presence services basically involve making the presence of a user visible to other users, which furthermore can be used to control other services in turn. This user profile comprises so-called “presence data” basically defining the state of the user and his/her equipment in any predefined respect. Thus, the term “presence” is here given a very broad meaning, and the following “user states” may for example make up the presence data:
A personal status, such as: available, busy, in a meeting, on holiday, etc.
A terminal status, such as: switched on/off, engaged, out of coverage, etc.                The geographic location of the user/terminal.        
Terminal capabilities, such as: functionality for SMS, MMS, chat, IM, video, etc.
Terminal selections, such as: call forwarding, language, etc.                Other information, such as: interests, occupations, personal characteristics, moods, personal logos, logo depending on the current mood, etc.        
All this information, or any selected parts thereof, is stored in the IMS network, based on so-called “publications of events” received from the network or a user whenever the user changes any of his/her presence data.
According to some services, it is possible for a user to subscribe for selected presence data of one or more other users, e.g. according to a list of users which may be either predefined, such as a phone book, or ad hoc, i.e. temporarily defined. A user subscribing for presence data will hereafter be called a “client”. Presence subscriptions are typically provided and handled by a functionality in the IMS of the client's access network.
A client may thus subscribe for presence data according to a list of users during a limited period of time, e.g. 12 hours. In one current implementation, the subscription period may be further extended upon request at any time before expiry. This service may be provided such that during the subscription time period, the client will receive a notification from its IMS network as soon as one of the users in the list has changed his/her presence data, such as having moved to another location. This is often referred to as a “push” behaviour. Alternatively, the client may subscribe for presence data by requesting presence data just once, thus allowing the client to fetch information when needed by request, i.e. a “pull” behaviour. Thus, each time the client requests for presence data, a “one-off subscription” is established, meaning that the subscription is valid for only one such delivery. The mechanisms for these services has been defined by IETF (Internet Engineering Task Force).
A basic procedure according to the prior art for providing presence data of a group of users to a client, will now be described with reference to FIG. 1, which illustrates schematically a typical communication scenario. In this example, a client 100 is wirelessly connected to a mobile access network 102, hereafter called “client access network”, and a number of other users 104 are likewise connected to various other mobile access networks IOβa-c. It is assumed that each of the involved networks 104, 106a-c is capable of providing the above-described presence service, e.g. by means of having the IMS solution implemented for each network. This means that each network has the necessary network elements, not further described here, to receive and handle presence data updates by the publication of events from connected users whenever their presence data is changed.
Moreover, the client access network 102 is also adapted to collect updated presence data of the users 104 from the other networks 106a-c, and to provide presence information on the users to the client 100, either by a push behaviour or a pull behaviour as described above. In the IMS solution, a network element called “Resource List Server (RLS)” is used for providing such presence information to the client. Of course, the other networks IOβa-c are also capable of providing presence information in the same manner to their respective clients, i.e. any user 104, in accordance with their subscriptions.
According to a previous solution, when the client 100 makes a one-off subscription request for presence data of a list of users 104, the client access network in turn sends a request, or “poll”, for presence data to each of the networks 106a-c to which the concerned users are connected. When the client access network has received responses, or notifications, from all networks 106a-c regarding the present states of the users 104 in the list, a notification is sent to the client containing the desired information on the users 104. This is a pure pull behaviour and can be repeated whenever the client desires to fetch such information.
However, this procedure is complicated and quite time-consuming, since the client access network must issue several requests and wait for notifications from all networks 106a-c, before sending the notification to the client. Moreover, the fetching of data will require considerable amounts of inter-network signalling, especially if many networks are involved. Upon repeated requests, some of the networks may also provide notifications comprising the same information with no updates, as compared to a previous notification. Hence, much of the inter-network signalling triggered by the client's request may even be unnecessary. In addition, when many different operators/networks are involved, standard procedures must be followed not allowing for internal and/or local optimisations.
Furthermore, in the current solution, information on all users in the list is sent to the client in response to his/her request, even if only some or none of the users have made any updates since last time. Therefore, the notification message sent to the client is always “full-sized” regardless of how many users that have actually changed their state since last time. As a result, unnecessary bandwidth for the wireless connection with the client 100 is occupied over a limited radio interface when the notification is sent to the client. In another prior art solution, when the client 100 has an ongoing time-limited subscription for presence data of the users 104, the client access network has in turn established a subscription with each of the concerned networks 106a-c, and thereby automatically receives a notification from any of the networks each time a user in the subscription connected thereto changes his/her presence data. Thereafter, the client access network sends a notification to the client containing the updated presence data, after each notification from the networks, according to a pure push behaviour.
The drawbacks of this solution is that the client may potentially receive a large amount of notifications, which will exhaust the battery power of the client terminal, and again, precious bandwidth is occupied for the client's wireless connection with the client access network 102 over a limited radio interface. Such problems can be partly overcome by the client access network setting a minimum time period between successive notifications to the same client, a so-called “rate limitation”. However, if the client really needs information in real-time, the rate limitation value must be set quite short such that the actual saving of notifications becomes insignificant.
In some known solutions, the client may also be requested to set a minimum time period between successive notifications, sometimes referred to as a “throttle time”. Nevertheless, the client will inevitably receive user information also when not needed, or even without noticing, e.g. if the terminal is inaudible. Furthermore, in the prior solutions, the client access network must establish a separate subscription for each user that on the client has requested information for, even when several users belong to the same access domain, resulting in many inter-network messages for a single client subscription.
When providing requested information to a telecommunication client regarding a plurality of users, it is desirable to generally reduce the signalling activities, particularly over the critical radio interface, without imposing unwanted delays, in the process of delivering such information to the client.